Most networks used today allow routing of small units of data, referred to as packets, based on destination addresses identified by the packets. In fact, communication via packet data networks that use packet transmission technologies such as, asynchronous transfer mode (ATM), frame relay and Internet protocol, has become a preferred data transmission strategy. Dividing data communication into packets allows sharing of a single data path between multiple users in the same network.
Interfaces between different networks such as enterprise networks and public data networks, typically have constrained resources, which are further explained below. Examples of interfaces include, but are not limited to, T1/T3 connections, and digital subscriber line (DSL) or cable modem type connections. The capacity of the above-mentioned interfaces is significantly less than the capacity within networks. As an example, it is standard to use fast Ethernet within an enterprise network, wherein fast Ethernet supports data transfer rates of up to approximately one hundred Megabits per second (100 Mbps). However, an interface between the enterprise network and a public data network may be a T1 connection, which supports data transfer rates of up to approximately 1.5 Mbps. Unfortunately, the maximum data transfer rate of the T1 connection is 1.5 percent of the maximum data transfer rate of the enterprise network. Therefore, packets that are to be transmitted from the enterprise network are queued and may ultimately be discarded after a timeout period as the packets wait to enter the constrained interface.
Quality of service (QoS) problems occur in packet flows due to packet processing constraints. As is known by those of ordinary skill in the art, QoS is a networking term that specifies a guaranteed packet throughput level. Since packets are typically lost after being queued for a brief period of time, it is difficult to guarantee a throughput level for a particular packet flow or destination.
Peering points between public data networks also have constrained interfaces that are typically a Gigabit Ethernet connection, an optical carrier three (OC3) connection or an OC12 connection. Fortunately, most network uses are tolerant of packet loss, and/or packet delays.
Many emerging types of peer-to-peer communication have real-time communication requirements. As an example, instant messaging from companies such as, but not limited to, Yahoo®, MSN®, and AOL® include options that allow users to speak to each other in near real-time, in addition to viewing each other. Voice over Internet protocol (VoIP) accommodates real-time communication requirements since VoIP requires real-time flows of packets. Specifically, VoIP sends digital voice information in discrete packets rather than in traditional circuit-committed protocols of the public switched telephone network (PSTN). Media gateways, such as the Sonus Networks of Westford Mass., USA, GSX-9000, are sources of real-time media flows. Many other types of bandwidth services have committed bit rates based on end-user requirements for process control and other private uses.
Therefore, since real-time communication is required, it is desirable to alleviate constrained resources introduced by typical interfaces between different networks. An example of a network that may require real-time communication is shown by FIG. 1. FIG. 1 is a block diagram of a prior art communication layout between a point-of-presence (POP) located within a public data network (PDN) aggregation point (referred to hereafter as PDN POP), a first aggregation realm 112 and a second aggregation realm 152. It should be noted that other networks 103 may be connected to the PDN POP 102. As known by those having ordinary skill in the art, a realm is a part of a network containing network devices. Examples of realm may include private networks, enterprises, etc.
As shown by FIG. 1, the PDN POP 102 contains an edge router 104 for routing data between the first aggregation realm 112 and the second aggregation realm 152 that are located downstream from the edge router 104 and separate from the PDN POP 102. Examples of edge routers include, but are not limited to, the Cisco 75xx, Cisco 10xxx and the Cisco 12xxx, manufactured by Cisco Systems, Inc. of San Jose, Calif., USA.
The PDN POP 102 also contains a first aggregation device 148, which is preferably a layer-two aggregation device. An example of an aggregation device may be an aggregation switch, such as the Lucent CBX500, manufactured by Lucent Technologies of Murray Hill, N.J., USA. The first aggregation device 148 allows communication between a first enterprise 121, a second enterprise 131 and a third enterprise 141 located within the first aggregation realm 112. In addition, via use of the edge router 104, the first aggregation device 148 allows communication between the first aggregation realm 112 and the second aggregation realm 152.
A second aggregation device 182, which is preferably a layer-two aggregation device, is also located within the PDN POP 102. The second aggregation device 182 allows communication between a first enterprise 161 and a second enterprise 171 located within the second aggregation realm 152. In addition, via use of the edge router 104, the second aggregation device 182 allows communication between the second aggregation device 152 and the first aggregation device 112.
The first aggregation realm 112 contains the first enterprise 121, the second enterprise 131 and the third enterprise 141. The first enterprise 121 contains a first access router 122, a first private data network 124 and a first computer 126 for use by a user. The second enterprise 131 contains a second access router 132, a second private data network 134 and a second computer 136 for use by a user. The third enterprise 141 contains a third access router 142, a third private data network 144 and a third computer 146 for use by a user. Each access router 122, 132, 142 located within an enterprise 121, 131, 141 provides a connection from a computer 126, 136, 146 to the PDN POP 102. Users of network services made available by the PDN POP 102 may be connected to the PDN POP 102 from within the PDN POP 102, or external to the PDN POP 102. A fourth computer 172 is illustrated by FIG. 1, which provides a user with direct access to the PDN POP 102 from outside of the PDN POP 102.
Each access router 122, 132, 142 provides a connection to one of the private data networks 124, 134, 144. As an example, the first access router 122 provides a connection to the first private data network 124. Each access router 122, 132, 142 also allows communication between a user, via a computer 126, 136, 146 and other portions of the first aggregation realm 112.
The second aggregation realm 152 contains the first enterprise 161 and the second enterprise 171. The first enterprise 161 located within the second aggregation realm 152 contains a first modem 162 and a first computer 164, for use by a user. The second enterprise 171 located within the second aggregation realm 152 contains a second modem 172 and a second computer 174 for use by a user. The first modem 162 and the second modem 172 may be digital subscriber line (DSL) modems, or any other category of modem.
Links connecting different portions of the PDN POP 102 may create constraints that force packets to be queued. The following provides an example of possible link properties within the PDN POP 102. Core network access links connecting the edge router 104 to devices within the PDN POP 102, such as Internet backbone routers (not shown), for example, may operate at OC48, which operates at approximately 2.5 Gigabits per second (Gps), or OC 192, which operates at approximately 10 Gbps. The edge router 104 divides communication between the first aggregation device 148 located within the first aggregation realm 112 and the second aggregation device 182, located within the second aggregation realm 152. Lines of communication between the edge router 104 and the aggregation devices 148, 182 typically operate at packet over synchronous optical network seven (SONET 7) or SONET twenty (SONET 20).
The aggregation devices 148, 182 decrease data transmission speeds to lower speed connections including, for example, frame relay over T1 or T3, asynchronous transfer mode (ATM) over T3, point-to-point protocol (PPP) over a high speed serial interface (HSSI) and/or DSL. The access routers 122, 132, 142 and modems 162, 172 terminate links from the aggregation devices 148, 182 and convert bandwidth flows to 10/100 Ethernet. Therefore, the slowest links are between the aggregation devices 148, 182 and the access routers 122, 132, 142 or modems 162, 172.
The edge router 104 is unaware of downstream bandwidth congestion. Edge routers may be programmed to build a queue for each logical end point in the POP PDN 102, thereby enabling a weighed fair distribution of packets based upon virtual downstream transmission capacity. Edge router weighted fair distribution queuing is not presently used to address bandwidth congestion for numerous reasons including, but not limited to, degradation in performance of the edge router and potentially complex provisioning mechanisms for which to plan.
To address bandwidth congestion after a fair distribution of packets has been weighed, it is generally believed that by recognizing which packets are associated with real-time requirements, edge routers and access routers can sequence packets to prevent queuing or discarding of packets. Unfortunately, techniques for identifying which packets are real-time packets require expensive packet classification microcircuits and configuration. Therefore, most existing edge routers and access routers would need to be updated or replaced.
In addition, once the real-time packets are identified, it is difficult to associate the real-time packets with an expected volume of packets to perform bandwidth reservation or allocation. To address difficulty in association of real-time packets, a resource reservation setup protocol (RSVP) device is typically used for requesting bandwidth and for requesting termination of RSVP requests at the edge router. As is known by those of ordinary skill in the art, RSVP is a protocol that allows a software application to reserve resources from a source to a destination along a routed path comprising one or more packet routers. Thereafter, RSVP-enabled routers may schedule and prioritize packets to fulfill QoS requirements. RSVP associates bandwidth requests with destination IP addresses, many of which are reused by enterprise firewalls. Therefore, a real-time flow could be replaced by a standard flow, however bandwidth allocation for real-time flows would be valid until an RSVP time-out.
Using the RSVP and the packet classification together would provide an enhanced capability for outbound flows from the enterprises. However, there is presently no mechanism to insert an RSVP request at an edge router for real-time flows originating from outside of the edge router. It should also be noted that in some signaling systems such as, but not limited to, session initiation protocol (SIP), the actual destination address may not be known at the time that it would be necessary to perform a bandwidth reservation.
Unfortunately, it is difficult for edge routers to identify and characterize the flow of packets since it is difficult to identify the start of a flow simply by observing individual packets. In addition, it is equally hard to characterize the end of a flow. To increase difficulty, many real-time flows utilize silence compression, which is defined by packet flows stopping during a duration of silence and beginning again when there is energy to transmit data packets. This inconsistency in the progression of packet flow causes difficulty in the identification of the start of a flow.
Bandwidth management at edges of networks has been researched via use of SIP, which is an industry standard signaling mechanism for session establishment. An Internet draft entitled “SIP Extensions for QoS Support in Diffserv Networks,” by Veltri Luca, having filename draft-veltri-sip-qsip-00.txt and being published October 2001, teaches the use of SIP extensions to manage and provision edge routers. To manage and provision edge routers, a SIP proxy determines which edge routers are ingress and egress routers from an administrative domain so that common open policy service (COPS) based policies for packet flows can be administered. As is known by those of ordinary skill in the art, COPS is a protocol used to transmit from a policy decision point (PDP) to a policy enforcement point (PEP). Unfortunately, there is no quality measurement included in deciding which edge routers are the ingress and egress routers and there is no flow interruption detection.
Similarly, an Internet draft entitled “SIP Extensions for Media Authorization,” by D. Evans et al., having filename draft-ietf-sip-call-auth-04.txt and being published February 2002, documents the utilization of a token distributed from a PDP to enable QoS based admissions to a network at an edge router. Unfortunately, the token does not include a measure of quality based on an originating realm that may be located downstream from an aggregation device located within a network. Additionally, policy-based admissions are being performed based on resources provisioned in the edge router that may not reflect downstream limitations.
The Internet draft entitled “A Migration Path to Provide End-to-End QoS over Stateless Networks by Means of a Probing-driven Admission Control,” by G. Bianchi, having filename draft-bianchi-blefari-end-to-end-qos-02.txt and being published November 2001, describes a technique for determining the quality of a packet flow prior to admitting the flow within a network. Quality determination is provided by a source transmitting a burst of packets as a probe to a destination test point located near the actual destination of the packet flow. This burst of packets is similar to what an additional multimedia flow would generate. By analyzing the performance of the returned packets from the destination test point, one could make an assumption about the quality of the additional multimedia flow. The source sends a burst of packets to the destination test point, which then transits the burst of packets back to the source. The source of the probe can then estimate jitter, packet-loss, and latency from the burst. As is known by those of ordinary skill in the art, jitter is a measurement of the variation of the gap between packets on a flow. An alternative definition is that jitter is the variance in latency for a multimedia flow.
The burst of packets is intended to resemble a packet flow requesting admission to the destination. Therefore, if the packet flow is, for example, a G.711 flow, the burst of packets reflects that the packet flow is a G.711 flow. Once the sender measures the quality of the packet flow, admission of the packets to the destination may resume. One problem with this technique is that it requires a destination address for the packet flow to be known prior to transmission. Many signaling protocols are routable or travel through proxies and gateways. It is often the case that addresses are not known until there is a successful setup of the packet flow via signaling. Unfortunately, waiting until there is a successful setup of the packet flow may be too late to stop the packet flow from alerting or ringing the destination. Therefore, a signaling system would announce the arrival of a communication session, before a bandwidth path has been allocated.
Still other deficiencies with the technique taught by G. Bianchi include an undesirable delay in learning bandwidth quality on an allocated path. This delay may be several hundred milliseconds in length. The delay may be acceptable if one destination is tested, however should there be several destinations, or if the test is performed multiple times throughout a multi-network arrangement (once in each network), the delay may be too large for real-time communications.
Another Internet draft entitled, “Session Authorization for RSVP,” by Hamer et al., having filename draft-ietf-rap-rsvp-authsession-02.txt and being published February 2002, describes an RSVP authorization element for session admission control. This element can be used to request bandwidth from an edge router that supports RSVP. Since edge routers are not currently capable of measuring quality on a flow-by-flow basis, there is no minimum required quality based admission control in the RSVP authorization element. Additionally, there is no support for downstream aggregation limitations that may be advisory. In addition, the RSVP authorization element is based on IP addresses. Since a protocol and port field are not mandatory RSVP fields, even if a source and destination IP address are supplied, the RSVP authorization element may not be capable of differentiating between a real-time transport protocol (RTP) flow and a file transfer protocol (FTP) flow arriving from the same network point. Therefore, a multimedia session may not be supported by RSVP authorization elements until the elements are protocol aware and session aware.
The Internet draft entitled, “A Framework for Policy-based Admission Control,” by Yavatkar, et al. and being published January 2000, further describes RSVP authorization elements. This Internet draft is concerned with specifying a framework for providing policy-based control over admission control decisions. Unfortunately, the Internet draft by Yavatkar, et al., does not describe flow-by-flow signaled admission and quality based admission.
An RSVP Internet draft entitled, “Edge Based Admission Control with Class Based Resource Management,” by Rawlins et al., having filename draft-rawlins-admctl-ds-mgt02.txt and being published February 2002, describes an upstream pool of bandwidth to be allocated by an Integrate services over the Internet (Intserv) class model. Unfortunately, quality measurements are not used in real-time admission control. Additionally, reservations of bandwidth are based on upstream limitations, instead of downstream limitations.
An Internet draft entitled, “A Protocol for RSVP-based Admission Control over IEEE 802-style Networks,” by Yavatkar et al. and being published May 2000, describes a subnet bandwidth manager protocol. The protocol is a signaling mechanism to insert a manager between a LAN and an RSVP based layer 3 routing network. However, this Internet draft does not contain a mechanism for performing admission control based on actual observed quality or on nested layers of aggregation links.
Sitara Networks of Waltham Mass., USA builds products that perform deep packet analysis to assist in support of VoIP in enterprise networks, an example of which is QosArray™. The QosArray product integrates high touch packet processing and classification with layer 2 quality schemes, such as 802.1p, and virtual LANs (VLANs), such as 802.1q, to prioritize VoIP at access points to constrained links, such as wide area network (WAN) connections between networks. The Sitara products are not signaling aware and, therefore, cannot reject a communication attempt. This may result in a packet flow being rejected, however neither the source nor the destination of the packet flow will be aware of the flow rejection. Rejection of the packet flow without notice will most likely result in an unexpected outcome.
Allot Communications, of Eden Prairie, Minn., USA, has developed a product referred to as the NetEnforcer™ that does special processing on VoIP packets to perform per flow queuing. The NetEnforcer™ also splits packets (e.g., a packet with 20 ms of speech is split into two packets, each with 10 ms of speech) to guarantee that there will be less latency injected on slow speed transmissions within a WAN. The NetEnforcer works in a COPS or RSVP based router network to perform packet admission control. Unfortunately, the NetEnforcer™ does not participate in signaling plans (i.e., SIP, media gateway control protocol (MGCP), H.323), does not measure packet quality in real-time and does not incorporate packet quality into an admission decision.
In addition, United States (U.S.) Pat. No. 6,404,864 (hereafter, the '864 patent), to Evslin, et. al. discloses a network routing scheme to control the routing of telephone calls based on quality measurements. The quality measurements are collected at the end of each call, tabulated, and used to make subsequent routing decisions. Therefore, quality is not measured in real-time. Additionally, the '864 patent does not describe advisory bandwidth limits per realm, does not disclose the notion of downstream or upstream networks, and does not prevent telephone calls from being admitted to a network. Instead, the '864 patent describes the controlling of routing once a telephone call is admitted to the network.
In summary, it is desirable to have packet flow control and QoS packet flow admission control, not only prior to entrance of packets to a network, such as the PDN POP 102 of FIG. 1, but also downstream from an edge router and as the packet flow leaves the network and is admitted to another network.